Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/034a/xrdor203.zip/NEWIN203.DOC

Text File | 1991-09-17 | 10KB | 169 lines

      XRS "eXpress Response System" <tm> Door version 2.03 changes:

Went back to the original release BC++ 2.0 to eliminate the bug in the newer
compiler which caused wierd "local" displays (although the user side was OK)



      XRS "eXpress Response System" <tm> Door version 2.02 changes:
            (since version 2.01)

1) PackBags.Exe is an automatic (pre-packing) mailbagger for XRSDoor.  It
scans through your QMX_CONF.SYS file looking for your "Priveleged" users
which you have marked with the "Prepack" bit-flag, and automatically creates
the files required and calls "XRSDoor!.Exe" (if it is not found "XRSDoor.Exe")
to do the actual extraction and compression.  Each person's pre-bagged mail
will be saved under a unique 8-hexidecimal digit name, with the user-selected
extent depending on which compaction he has chosen (i.e. "2fa839d1.ZXR" up to
*.ZX9, assuming the user selected PKZip packing - at most 10 files saved for
any one user.  PLEASE BE CERTAIN YOU HAVE XRSDOOR SETUP AND OPERATING PROPERLY
BEFORE YOU EVEN THINK ABOUT IMPLEMENTING THIS PROGRAM!  You must chose which
users are allowed to have prepacked mail by using the "XRUserEd.Exe" program
that comes with XRSDoor (set the 'P' bit - "Prepack" under the "Toggle switch"
submenu).  I would suggest that you only run PackBags once a day, in which
case it will store up to 10 mailbags for a user while they are on vacation,
etc.  (once it has 10 mailbags on "hold" it will not pack any more for that
user)  PackBags stores its log in a separate "PackBags.LOG" file which you
may wish to delete occasionally, after assuring it is working correctly.
          * * * * * *  W A R N I N G  * * * * * *
Please be careful here - you can easily get into the habit of saving 100's of
kilobytes of mail for people, which XRSDoor is designed to avoid (i.e. prepack
problems associated with supporting a large number of "real" points).  This
feature should be reserved for your best users depending upon your disk drive
capacity, etc.  Using this feature wisely to give your best XRS users mail on
demand (and prepacking during the "midnight" or one event early each day) can
save users still more time online (and give you an opportunity to have more
users online per day, too!).

2) Several minor changes were made to accommodate "PackBags.Exe" - the
automatic mailbagger.  XRSDoor was also modified to look for the special
saved files, and offer to download them as soon as the user comes into the
door the next time (or he may chose to defer or store them until later, or
delete them).  PackBags creates a mailbag with a unique name by performing a
32-bit CRC on the username, and renames the normal output file.  XRSDoor now
knows the 'named mailbag' name for saved mailbags for each user.  For the time
being, batch protocols only (True Y-Modem, Z-Modem or G-ymodem) must be used.

3) The FOSSIL input routine immediate "timeout" if the user started XRSDoor
within three minutes before midnight is fixed.

4) New QMXSETUP.CFG parameter "Minimum xxx" allows you to set a minimum count
of new messages in the mail databases before XRSDoor.Exe will prepack mail -
range is from 50 to 1000 messages.  It only affects XRSDoor when it is called
by PackBags.  I would suggest that you set it to at least 250 messages - note
that the maximum number of messages packed (which has nothing to do with how
many new messages total are on file) is going to always be the number you set
using "Limit" parameter, which will avoid creating bundles too large for your
your users.  The default is 250.  Setting this to a reasonable number, say
500 or 1000 (depending on the average daily volume of mail coming into your
system) gives you the ability to prepack mail more often, but only when a
certain minimum number of new messages have been received.

5) New QMXSETUP.CFG parameter "PackbagPath xxxxx" allows you store prebagged
mail in another subdirectory insteaed of the current directory.  Parameter is
*REQUIRED* for multi-node systems to work properly, and in this case must give
a complete PATH.  THE SUBDIRECTORY *MUST* BE ON THE SAME DRIVE!  For single
line systems, using "PackbagPath C:\SaveBags" would store prebagged mail under
a subdirectory named "SAVEBAGS" off the root of the C drive for example, and
"PackbagPath C:\QMX\SAVEBAGS" would save all packed mail in that subdirectory
for a multi-line system.  Be sure to include the complete path - be certain
that it already exists! (and that it is on the same drive)

6) New QMXSETUP.CFG parameter "GMODEM" enables G-Modem for selection.  Prior
versions always showed it, even though it may have been inappropriate.  If you
have an error-correcting modem, you should turn this on, otherwise it will no
longer be offered.  Note that if you don't have a registered copy of DSZ.COM
or GSZ.COM, this parameter will not function, anyway!

7) Normally, "PackBags.Exe" searches QMX_CONF.SYS for users the SysOp has
marked for PrePack, creating the EXITINFO.BBS and DORINFO1.DEF files for each
user and calling XRSDoor.  If you type a name on the command-line, PackBags
only looks for a matching username in the file, and if found creates the two
required files, packs mail for that one person (without regard to "Minimum")
and exits.  This allows "On Demand" packing (for someone not necessarilly
marked for prepacking) - this might be used for a "Mailer Request" function.

8) PackBags knows nothing about which type of Hudson-style BBS it is running
on, and needs to know if the USERS.BBS and/or QMX_CONF.SYS files are hiding
in another subdirectory.  If one (or both) are, use a new "MessagePath xxxxx"
QMXSETUP.CFG parameter, where 'xxxxx' is the path to the file(s).

9) The error which allowed users to send "Crash" netmail if they had the
"Prompt for maximum number of messages" bit set is fixed.  Note that XRSDoor
determines whether or not a user has "Crash" priveleges solely by the flag in
QMX_CONF.SYS (which you set with XRUserEd.Exe) - it pays no attention at all
to any other settings.








      XRS "eXpress Response System" <tm> Door version 2.01 changes:
            (since version 2.00)


1) Fixes problem with RA 1.10 versions, which provide the true carrier rate
for new connect speeds when used with the new CCITT V.32bis modems.  XRSDoor
now recognizes 14400, 12000 and 7200 BPS rates as legitimate.

2) You can select "AR<J>" from the compression type selection sub-menu in the
configuration section.  The menu which was previously here has been replaced
with a simpler one-line prompt.  XRSDoor defaults to "PKZip" for packing.
ARJ is only recognized by XRS 4.50 versions dated June 15th, 1991 or later!

3) "InDir" can be on another drive, allowing you to use a RAM-disk, etc.

4) XRSDoor recognizes and includes "4D_PACK.XRS" in every mailbag if you
place that file in your subdirectory (content unimportant - can by 0 length).
This forces XRS 4.50 versions dated June 15th, 1991 or later to return you a
true 4D packet with zone:net/node.point all filled out in the *.PKT header.
IMPORTANT NOTE:  DO *NOT* USE "POINT 0" IN COMBINATION WITH 4D_PACKing! (the
result will be that both the 4D "from" and "to" addresses are idential...)

5) A new "XRUserEd.Exe" is included that will show/set "ARJ" for compression.
XRUserEd requires both the file "XRS$ALL.DTA" and "XRS$CORE.RTL" found in the
XRS release archives.  Also, note that you must be in the same directory as
the "QMX_CONF.SYS" file when you run it (and if "AREAS.BBS" is in a different
subdirectory, that subdirectory must be used as a command-line parameter).

6) "Alien" uploaded files are moved to a subdirectory named "XRS_DOOR.BAD"
and deleted from the "InDir" (anything that cannot be unpacked/interpreted).
If the subdirectory doesn't exist, XRS creates it.

7) "MSGTOIDX.BBS" is no longer left open during message pack and download.

8) The "Clean_Up()" routine is executed as soon as files are successfully
compressed instead of after the download is completed.  This eliminates all
of the *.XRS files packed into a mailbag before the transfer, optimizing use
of disk space (especially important on multi-line systems / large mailbags).

9) XRS can use the new "GSZ.EXE" (full-screen version of DSZ).  Put "Use GSZ"
into your QMXSETUP.CFG file, it is used instead of DSZ.COM for transfers.

10) If "MkXrs" is called to import mail after an upload, the "HighMsgRead"
pointer is updated properly, so users with the "Include" (from me) toggle on
do not see their own messages twice - when they are uploaded and next time.

11) If the file "QUICKCFG.DAT" is found, QuickBBS 2.75 or later format files
are used and RA and SuperBBS support checks are bypassed.  XRSDoor uses that
file and "MSGCFG.DAT" instead of CONFIG.BBS (or CONFIG.RA and MESSAGES.RA).
(note - this includes full multi-line support with file-sharing)  XRSDoor
also recognizes AKA addresses for QuickBBS 2.75 and later.   XRSDoor pulls
the node number for Quick275+ from the QUICKCFG.DAT file and ignores the "SET
TCNODE=x" in the environment (if any).  If multi-line QuickBBS 2.75 or later
is being used, the "QMX_CONF.SYS" (user default selections file) is kept in
the message subdirectory - if you now have it somewhere else (in the current
directory) you *MUST* move it!  The "SET QUICK=xxxx" environment string is
used to find files (i.e. "xxxCFG.DAT") if they are not in the current dir.

12) The availability of "Crash" netmail works for any version of QuickBBS.

13) XRSDoor puts the alias supported by RA 1.0 and later or QuickBBS 2.75 and
later into the USERx.XRS file for use by future XRS versions.

14) The status bar no longer scrolls up (and off) the screen if you have lots
of new files displayed.